1. Field of the Invention
This invention relates to synchronizing source code, and particularly to synchronizing independently updated source repositories.
2. Description of Background
The source code for software projects of all kinds (commercial, private, academic, governmental, open source, etc.) is routinely, universally, kept in specialized source code databases or repositories. Source code is represented as text files. Major software projects can have many thousands of such files, and scores of programmers making changes to various ones of these files. The primary purpose of source code repositories is to control and track changes to the source code and related (e.g., build, XML, configuration, documentation, test data, etc.) files. Various code control repositories are in widespread use (e.g. RCS (Revision Control System), SCCS (Source Code Control System), CVS (Concurrent Versions System), Subversion, CMVC (Configuration Management Version Control), Rational's ClearCase, Microsoft's Visual SourceSafe, etc.).
In the large and growing world of open source, CVS is the most common, with Subversion gaining ground. For example, SourceForge's 116,000+ registered projects use CVS. There are two defining dimensions to open source; the ability to access (read) & use (reuse) the source code, and the ability to update (write) the source code. Sometimes in an open source project there are occasions when the second ability is perceived as limited for various reasons. In such cases, the first aspect of open source is exploited to ‘fork’ the code. That is, the group desiring a different direction can make their own copy in their own repository and then proceed in parallel, perhaps completely independently, of the original code base. The two (or more) code bases will diverge over time, and this can result in incompatibilities and inconsistencies as exploiters (including businesses) of the code try to choose which path to follow. The developers of the original code base must also often make a decision to commit their time to one or the other. A desirable feature that shows up in the original can be difficult to include in the other. These kinds of eventualities tend to marginalize the original code base and its impacts on IT can be lessened. Hence, though the ability to fork has been termed the essence of open source, actually doing so is generally considered undesirable, as it also tends to split the efforts of everyone involved.
At the same time, the pressure and advantages of forking a code base can be quite compelling. Thus, there is a need in the art to provide the advantages of forking without incurring, or at least mitigating, the disadvantages.